The invention relates generally to information and computer systems and networks security, and more particularly to a method and system for assessing the cumulative access entitlements of an entity, for example a user, or a collective thereof, of an information system.
It may be noted that from hereon, the word entity and user may usually be used interchangeably. It may additionally be noted that a user's security affiliations include the user's identity.
It may further be noted that from hereon, the terms administrative tasks, business tasks, business functions and computing tasks all serve to denote the various abilities to which the entities of an information system may be entitled by virtue of the cumulative access entitlements that exist in the information system for these entities. These terms may thus be used interchangeably from hereon in this document.
Information Systems & Information Security
An information system may be viewed as one comprised of (i) a standalone computing device or a networked set of computing devices, that usually exist to provide some computing service, and that usually run some sort of a control program such as an operating system, and that are usually referred to as IT assets, and the information system may optionally be additionally comprised of and (ii) the information assets that these entities may create, consume, store, process, share and manage as a part of their work. In some instances, an information system may also be considered to comprise (iii) a set of entities, for example users, that use these IT assets (for example computing devices and the services they offer)
Information security has become an important aspect of doing business today. Every IT and information asset should be adequately protected across all aspects of its lifecycle (i.e. creation, storage, communication and consumption/use) to a degree consistent with the value of the asset. Thus, most information systems usually provide a fundamental set of security services that together deliver numerous protection capabilities that preferably enable the protection of information assets.
A set of security services usually includes authentication, authorization and, at times, auditing. Authentication usually involves limiting access to the information system to a known and identifiable set of entities, for example users. Authorization, also referred to as access-control, usually involves the specification and enforcement of authorization intent dictating the type of access a user of an information system has on an information or IT asset, or a set thereof. Auditing, an accountability measure, is usually the means by which a record of an occurrence of a computing/business task/action by an entity of the system can usually be created, ideally irrefutably, and usually archived.
Authorization
Every IT and information asset usually has an owner who usually has complete control over that asset and can thus usually also authorize other users of the information system to access that asset. Access to an asset is a generic term, and is usually qualified by specifying the nature of access authorized, such as read, modify, create and delete access. In addition, the owner of an asset may also grant (or authorize) another entity such as a user, or a set of entities, such as a group of users the ability to control access to the asset itself. Finally, the ownership of an object can usually be transferred, and in certain cases, also be seized by another user whose administrative powers exceed or equal that of the current owner of the asset.
The act of specifying who has what access to an asset is usually referred to as specifying authorization intent. An information system preferably allows entities, such as users, to specify authorization intent for protecting IT and information assets. In addition, in certain information systems, the system itself usually ships with some pre-specified basic level of default authorization intents specified on information and IT assets, usually aimed at providing varying levels of default access to different generic sets of users in the system. In most systems, the combination of system pre-specified authorization intents and user-specified authorization intents is usually collectively enforced when a user of the information system attempts to access this information/IT asset. Also, in most systems, access is usually enforced by means of an access check.
Authorization and Entitlements
As it pertains to information security/access control, in most systems, authorization involves the specification and enforcement of authorization intent which dictates the access an entity has on an asset. This authorization intent, in effect authorizes the entity to perform a specific system-level operation on the securable resource that it serves to protect.
In most systems, the specification of authorization intent almost always involves an explicit grant or denial of some low-level (system-level) permission that authorizes the ability to perform a corresponding system-level operation on some securable resource or on some unit of data that may either itself constitute, or be a part of a securable resource, which in turn by itself or as a part of a bigger collective, may represent a unique information or IT asset.
Also, in most systems, by design, a system-level operation that is performable on a specific type of unit of data in the system may correspond to a specific high level administrative task or business function that may be performable in the system. For example, a low-level create operation involving the creation of a data structure representing a user account in the system, corresponds to a high-level administrative task of creating a user account for an entity in the system.
Consequently, existent authorization intent, in effect also entitles the entity to be able to perform a specific administrative task on the asset that it serves to protect; the specific administrative task entitled being a function of (i) the specific system-level operation authorized and (ii) a function of the type and nature of this securable resource.
It thus follows that in most systems, the ability of an entity, such as a user to perform a specific high-level administrative task or business function is dependent on the existence of permissions specified in authorization intent specifications for that entity in the system, that authorize the execution of the system-level operation that corresponds to this high-level administrative task.
It thus also follows that in most systems, while each individual authorization intent specification explicitly governs the ability of an entity, such as a user, to perform a system-level operation on some securable resource, more importantly, it implicitly governs the ability of that entity to perform a high-level administrative task on information or IT asset that the securable resource represents.
It finally follows that as it pertains to information security in general and authorization in particular, every existing authorization intent specification on some securable resource, authorizes the entity specified in that authorization intent specification to perform a specific system-level operation on the securable resource that it serves to protect, and in effect also entitles this entity to be able to perform a specific administrative task on the information or asset that this securable resource represents.
Authorization, Permissions, Operations and Entitlements
The nature of the permissions specified in an authorization intent specification in an information system is usually a function of the underlying implementation of the authorization model and the security resource managers that provide the means to specify authorization intent.
In most information systems, permissions specified in an authorization intent specification that serve to protect a securable resource, typically authorize the subject of the permission to being able to perform some form of system-level operation on the resource. However, in most information systems, the ability to perform a specific system-level operation on a specific type of resource may or may not directly correspond to the ability to perform a specific business level administrative task or function on the business asset represented by that securable resource.
In certain implementations, the set of permissions that may be specified in authorization intent specifications (or the system-level operations that the permissions serve to authorize) directly correspond to a set of specific business or administrative functions, in that the intent, the act and the effect of specifying a permission in an authorization intent specification for an entity, are tantamount to the intent, the act and the effect of authorizing the entity (specified in that authorization intent) to engage or enact the specific business or administrative task or function that maps to this permission. In this case, the presence of a specific permission directly entitles the entity to perform a corresponding specific administrative/business task/function.
In such implementations, an inspection of the permission in an authorization intent specification for an entity readily provides an unambiguous indication of the specific business or administrative function that this intent specification serves to authorize and entitle for this entity.
In other implementations, the set of permissions that may be specified in authorization intent specifications (or the system-level operations that the permissions serve to authorize) do not directly correspond to but rather indirectly map to a set of specific business or administrative functions, in that while the act of specifying a permission in an authorization intent specification for an entity may or may not be intended with the specific purpose of authorizing the entity (specified in that authorization intent) to engage or enact the specific business or administrative function that maps to this permission, the effect of specifying this permission is tantamount to the effect of authorizing the entity (specified in that authorization intent) to engage or enact the specific business or administrative function that maps to this permission. In this case, the presence of a specific permission indirectly entitles the entity to perform a corresponding specific business or administrative function.
In such implementations, where permissions indirectly entitle administrative tasks, there exists a mapping between the set of permissions that may be specified in authorization intent specifications and the set of business or administrative tasks or functions that these permissions have the effect of authorizing for an entity. This mapping introduces a gap in a system and the users of a system are required to be aware of this mapping and manually bridge the gap between the specific permission specified in the authorization intent specification and the corresponding business or administrative function that the existence of this permission ends up authorizing, both during the specification of and during the assessment of authorization intent.
In such implementations, the act of entitling an entity to a specific business or administrative function and the act of assessing the set of entitlements conferred upon an entity, both require the inclusion of this set of mappings between permissions and administrative tasks. This set of mappings is usually delivered in the form of documentation provided by the vendor of the underlying operating system. In some cases, the vendor of the underlying operating system may implement a partial set of such mappings in the user interface that allows users to specify permissions on resources. NOTE: In most information systems, there is typically a one to one correspondence between the permission specified in an authorization intent specification and a specific system-level operation. Thus there typically also exists a mapping between the set of resource-type specific system-level operations (that may be authorized by permissions specified in authorization intent specifications) and the set of business or administrative tasks or functions that these permissions have the effect of authorizing for an entity. Thus, either a set of permission to administrative task entitlements, or a set of system-level-operation to administrative task entitlements may be used to assess the administrative tasks entitled by the presence of specific permissions in authorization intent specifications protecting a securable resource.
In such implementations, an inspection of the permission in an authorization intent specification for an entity, by itself, in no manner provides any indication whatsoever of the specific business or administrative function or functions that this intent specification serves to authorize and entitle for this entity.
It may be noted that while in both implementations, the act of authorizing some access to some user, which involves specifying some permission for the user on an information or IT asset, as manifested in an authorization intent specification, has the effect of entitling the user to perform some administrative task or business function, the act of inspecting the access specified in an authorization intent specification may or may not readily provide an indication of the specific business or administrative function that this intent specification serves to authorize and entitle for this entity. Thus, the nature of the permissions specified in an authorization intent specification in an information system can significantly impact the ease with which an entity's entitlements may be assessed.
The native authorization models of most commercially available operating systems such as Microsoft's Windows family of operating systems primarily implement an authorization scheme where permissions are used to specify access on securable objects and for the most part these permissions do not directly correspond to but rather indirectly map to specific business or administrative functions. Thus, in most information systems, the determination of an entity's access entitlements is a highly non-trivial, complex and intensive task.
Cumulative Entitlements
As it pertains to an entity, such as a user of an information system, the entity's cumulative entitlements refer to the resultant set of all administrative tasks/business functions that the entity is authorized to (i.e. entitled to) perform by virtue of the cumulative access granted to this entity or any of its security affiliations, across the information system, or a specified subset thereof, as specified in authorization intent specifications that serve to protect individual or collective information or IT assets and that cumulatively govern the overall access granted or denied to this entity or any of its security affiliations, across the information system, or a specified subset thereof.
For example, consider an information system comprised of a set of information and IT assets and a set of administrators and users. The system administrators may over time grant various permissions to various users in effect authorizing them the ability to perform certain administrative tasks. Note that different administrators may grant the same user different permissions in different parts of the system, so as to authorize for the user, the ability to perform some business function or administrative task, as dictated by the business needs. At any given point in time, the user's cumulative access entitlements would then consist of the set of all administrative tasks across the entire information system, that are authorized by the presence of all existent permissions that grant this user or a security group that the user is a member of, some form of access on some information or IT asset across the information system, which in effect entitles the user to perform some administrative task of business function related to that information or IT asset.
Cumulative Entitlements and their Assessment
In most information systems today, there usually exist a large set of authorization intent specifications across the information system. Each expression of authorization intent is usually implicitly or explicitly tied to the asset that it serves to protect and at a minimum specifies the entity i.e. subject or principal for whom access is being specified and the nature and optionally the level of access that is being specified. An information system usually offers the means by which its entities, such as users, can be represented and uniquely identified and authenticated. In addition, most information systems usually also offer the means to collectively specify a set of entities, such as users, for the purpose of specifying authorization intent. While such means could take many forms (e.g. groups, roles etc.) the system ensures that each such collective can also be uniquely identified. Thus, at its simplest, usually, every expression of authorization intent includes a unique identifier for an entity such as a user, or a collective of entities for whom access is being granted.
As it pertains to scale, the simplest information system is one that is comprised of a single computing device representing a single IT asset and a set of zero or more information assets that exist on that device, and finally a single entity, such as a user of the information system comprised of the above information and IT assets. In this simplest of cases, there would be an expression of authorization intent governing this entity's access (use) to the computing device (an IT asset) and further one or numerous expressions of authorization intent governing the entity's access to the various information assets that exist on that computing device.
On the other end of the scale spectrum, a large and complex information system could be comprised of a very large number (to the tune of hundreds of thousands or even millions) of connected computing devices (representing IT assets) with an equally or exceedingly large number of information assets collectively being stored on the entirety of these devices and finally a very large number of entities, such as users, of the information system comprised of the above information and IT assets. In this case, there would be a very large collective number of expressions of authorization intent governing various aspects including individual and collective accesses to computing devices (IT assets) and governing the various ways in which the large number of entities, such as users, of this system may individually and collectively access any/every one of a large number of information assets that exist on that entirety of this large number of computing devices.
As it pertains to an individual entity, such as a user, this implies that that the cumulative set of authorization intent specifications that exist for a specific entity across the information system, is comprised of the collection of a large number of individual authorization intent specifications, each of which (i) are usually specified as a part of a set of authorization intent specifications on one of a large number of individual information or IT assets across the information system, each of which may be owned or managed by numerous other entities (ii) are usually specified by another entity in the system, who typically own or manage these assets and (iii) each of which specifies permissions either for this specific entity or for some collective to which this specific entity belongs.
For example, consider an information system, in which there exist thousands of individual information and IT assets and hundreds of users. Each information and IT asset usually has an owner who specifies authorization intents protecting these assets. These authorization intent specifications are usually specified in an authorization list protecting the asset and each individual authorization intent specification specifies the nature and type of access granted for others users and groups in the information system. Thus, for a given user, there may exist thousands of individual authorization intent specifications each existing in authorization lists on hundreds of information or IT assets, and each specifying some access either for this user or for a group to which this user may directly or indirectly belong. Also as illustrated by this example, each of the hundreds or thousands of information or IT assets, whose authorization lists contain authorization intent specifications for this user, are usually owned or managed by a large set of different users.
Additionally, as mentioned above, in most information systems, these authorization intent specifications explicitly only authorize low-level operations on data; thus introducing a gap wherein the corresponding high-level administrative tasks or business function that is authorized needs to be somehow inferred by the user or an administrator of the system.
It may further be noted this large set of authorization intents is neither specified by a sole entity (user) nor is a sole entity (user) in the know of the entirety of authorization intents that exist across the information system. On the contrary, the individual acts involving these specifications of authorization intent are usually independent events enacted by a large number of unique entities of the system, each typically motivated by a desire or a need to protect individual information/IT assets. Additionally, unbeknownst to any one single entity, in their entirety the specified authorization intents cumulatively and implicitly or explicitly result in a large set of authorizations for a large set of entities, such as users, across the information system. It may also be noted that in most information systems today, as such, no single entity (user) is usually in the know of the entirety of authorization intents to which they themselves or another entity may be authorized access. As noted above, the word entity and user may usually be used interchangeably. Also, as noted above, unbeknownst to any one single entity, in their entirety the specified authorization intents cumulatively and implicitly or explicitly result in a large set of authorizations for a large set of users, across the information system.
As a consequence it follows that every user in an information system is in actuality implicitly or explicitly entitled to a large set of specific business or administrative tasks or functions, the collective scope of which may span large parts of the information system. It was also noted above that the large set of authorization intents that exist in an information system are neither specified by a sole entity (user) nor is a sole entity (user) in the know of this entirety.
As a consequence, it follows that, in most information systems today, the cumulative set of a user's entitlements are neither known to the user him/herself nor known to any other single entity in the information system. Also as noted above, the users of an information system usually have a business need to be able to specify authorization intent in terms of authorizing the ability to perform administrative tasks. However, most implementations only allow users to specify low-level permissions in an authorization intent specification. Thus, in most implementations, there exists a mapping between the set of administrative tasks and the corresponding set of low-level permissions on specific data types that are required to authorize these administrative tasks. The users of such a system are required to be aware of and take into account this mapping both while specifying authorization intent and while determining the set of entitlements that exist in a system for a user. In such implementations, it could very well be the case that a user while specifying authorization intent for a specific information/IT asset may not completely understand or be unaware of the ramifications of granting a specific type of access on that asset to a specific user or a collective of users.
As a consequence, it follows that there may exist authorization intents for a user of a system that end up entitling the user to specific business or administrative functions that in fact were never meant to be authorized for that user, but that nonetheless are authorized, primarily because of human error introduced during the act of authorizing access.
Furthermore, when granting access to a collective of users, the owner or the manager of an asset, may not realize that anyone who controls or could obtain the means to control or modify the membership of that collective could in effect end up implicitly authorizing access for another entity to this asset, even though the owner or the manager of the asset who used that group to specify access to this asset, may never have intended to allow such access to the additional entities that may now be a part of that modified collective, and thus have access to that asset by virtue of being a member of a collective to which this owner or manager ha authorized access. As a consequence, it follows that there may exist authorization intents for a user of a system that end up entitling the user to specific business or administrative functions that in fact they were never supposed to possess or acquire the ability to engage in.
Thus, it follows that the cumulative entitlements of users in an information system may (i) be very large, (ii) span various parts of the information system, (iii) in its entirety, neither be known to the user him/herself nor to any other entity in the information system, including the administrators of the information system and the owners of various information assets and finally (iv) entitle the user to excessive access i.e, the ability to perform specific business or administrative functions that in fact they were never supposed to possess or acquire the ability to engage in, from the perspective of business policy.
Ramifications of Excessive Cumulative Entitlements
The presence of excessive or unauthorized (by policy) entitlements in an information system significantly endanger the entirety of an organization's information and IT assets. Furthermore, their oblivious continued presence poses a greater risk because it allows such vulnerabilities to go unnoticed by administrative or security personnel and exist for long periods of time, thereby significantly increasing the likelihood of the discovery and subsequent misuse of these vulnerabilities by malicious individuals.
To be more specific, the presence of a user's excessive entitlements can be grossly misused either by the user or by any malicious party that may come to learn of their existence either accidentally or intentionally. A malicious user could misuse the presence of excessive entitlements and the knowledge thereof to escalate his/her privilege and potentially compromise one or more information or IT assets to which he/she him/herself may not be authorized access. A shrewd malicious user could not only compromise another asset but also implicate the user whose entitlements were used to compromise the asset thereby causing harming to the user whose entitlements were misused and leaving the victim user with no way of claiming or providing proof of his/her innocence.
A Real World Illustration
This problem is best illustrated by a real example of its manifestation in over 80% of IT information systems across the world, each of which run on Microsoft Corporation's Windows server and client family of operating systems. It is a well established fact that information security is fundamentally about access management. Access management involves the authentication of users, the authorization of access to resources and the auditing of the execution of some user-specifiable administrative/computing tasks/functions. These facilities in turn require the presence of user accounts for user identification and authentication, and it also requires the specification of authorization intent on resources, so as to be able to specify who has what access on a given resource.
In information systems running on Microsoft's Windows server and client family operating systems, at the heart of access management is the Active Directory, an enterprise directory service that plays a central role in user authentication, resource authorization and access auditing, in addition to playing the role of an enterprise directory that is used for resource location.
From a technical perspective, the Active Directory is a hierarchical, object-oriented information store. It ships with a schema that contains pre-defined definitions of numerous object classes, each comprised of a finite set of attributes. The purpose of each object class and attribute in the schema is defined by the designers of the Windows operating system. These schema definitions define objects that represent users, security groups, computers, printers and other resources.
In a Windows Server based information system, user accounts are represented by instantiations of objects of class user in the Active Directory; similarly security groups and computers are represented by instantiations of objects of class group and computer respectively. The same is true for various other categories of resources including printers and service connection points.
One consequence of the above aspect is that in a Windows Server based IT infrastructure, administrative tasks associated with the management of resources involve the creation of specific object types in the Active Directory and the initial setting and subsequent modification of the values of the attributes that these objects are compromised of.
For example, the administrative task of creating user accounts amounts to the creation of an object of class user in the Active Directory. Similarly the administrative task of creating security groups amounts to the creation of an object of class group in the Active Directory. On the same note, the administrative task of disabling a user account involves the modification of the user-account-control attribute on the specific user account object, and the administrative task involving the modification of a security group membership involves the modification of the member attribute on the group object representing that group.
In this manner, almost every administrative task in almost every administrative category such as account, group, computer and printer management, involves the creation, modification or deletion of object classes and attributes in the Active Directory. Microsoft Windows based information systems are usually large and comprise of thousands of user accounts, computers, security groups and resources, each of which needs to be managed. Because it is infeasible for a small set of administrators to manage such a large set of resources, Active Directory offers a powerful capability that allows administrators to distribute and delegate the various aspects of management of these resources between a large number of relatively less powerful administrators and between the users of the system themselves.
This powerful capability is enabled by Active Directory's authorization model, which provides administrators the ability to grant a user or a security group a set of specific permissions on objects in the Active Directory. Each object is protected by an access control list (ACL), which contains a set of zero or more access control entries (ACEs), each of which specifies a set of one or more permissions for a user or a security group on that object.
In Active Directory, there exist a basic set of permissions corresponding to the basic low-level operations that can be performed on objects and attributes. These basic low-level operations include list (a) child (object), create (new instance of) object, delete (an existing instance of) object, read-property (i.e. attribute), and write-property. The basic set of corresponding permissions in Active Directory include list child, create object, delete object, read-property and write-property. In addition, there also exist certain advanced permissions such as modify owner and modify permissions, and there exist a small number of specific special permissions. Together, these set of permissions in Active Directory control the ability of a user to perform a low-level operation on an object
Each basic low-level data operation on a specific class of object or one of its attributes maps to a specific administrative task and thus entitles a user to perform some administrative task. Most administrative operations involve the creation or deletion of objects and/or the reading or modification of attributes on objects. Because Active Directory provides the means by which each of these low-level operations can be authorized to a user, in effect Active Directory allows administrators the ability to grant lesser privileged administrators and user themselves the precise set of permissions (on specific objects) that are required to perform one or more administrative tasks. In this manner, administrative entitlements are conferred upon lesser privileged administrators and users themselves.
It is not uncommon for a lesser-privileged administrator to be granted permissions on thousands of objects over the lifetime of their employment in that capacity. Also, in many cases delegated administrators may themselves be allowed to further sub-delegate administrative authority to other delegated administrators and users.
Over a long period of time, hundreds of administrative personnel and users may end up having permissions granted to them on thousands of different objects in the Active Directory. Over time, it may also very well be that while the administrative responsibilities assigned to a delegated administrator may change, the set of permissions assigned to him/her or to a group to which he/she might belong may not be removed, either due to administrative oversight or for a variety of other reasons, and thus may continue to exist thereby continuing to allow him/her the ability to perform an administrative task to which he/she should ideally no longer be entitled to perform.
It may be noted that a simple evaluation of these permissions will in no manner allow a user to infer the set of administrative tasks that these permissions grant to a user or to a group. This is because while Active Directory allows for permissions to be specified, it provides no facility for an administrator that is specifying a permission to describe or annotate it with the reason or intent governing the specification of this permission. Thus, while the ACEs in the ACLS on each one of thousands of objects in the Active Directory specify what permissions a specific user or group has, they do contain no information that might provide any indication as to why that permission exists in that ACE. As a consequence, when an administrator views an ACL on any one of thousands of objects in the directory, all he or she sees is a list of low-level permissions granted to a set of users or groups.
A related issue is that of attempting to determine the list of all users to whom a specific administrative task may be authorized by virtue of an ACE that exists on an object that grants some permission to a security group. The mere evaluation of this ACE will neither reveal what administrative task it entitles the members of this group to, nor will it reveal the members of this group. Furthermore, it is not sufficient to simply read the member attribute of the corresponding group object in Active Directory, as group memberships can be transitive in nature, and this transitive in nature is not reflected in the member attribute of the group object—it must be evaluated. For example, a group could be a member of another group which in turn could be a member of another group. A simple inspection of the member attribute of this third group will only reveal that the second group is a direct member of it; it will not reveal that the first group in turn is a member of this second group and thus in fact is also a member of the third group. Thus, a simple evaluation of these permissions will in no manner provide any indication as to the entire set of users that may be entitled to performing either the low-level operation or the corresponding administrative task that corresponds to the presence of those permissions on that object.
It may also be noted that for any given user, the set of permissions that cumulatively allow him or her (either directly or transitively) the ability to perform a set of low-level operations on a set of objects (, and thus perform all corresponding high-level administrative tasks,) may exist in thousands of ACEs, each one belong to the ACL of one of thousands of objects. It may further be noted that these permissions would typically not have been provisioned by a single administrator, but rather provisioned by numerous administrators, each of whom may belong to different groups, and may only be responsible for managing isolated subsets of resources. Thus, in all likelihood, no single administrator in the system would know about the entire set of permissions that exist for any one of thousands of users or security groups.
As a consequence, it may very well be that a user or a delegated administrator may be entitled to performing a large set of administrative tasks in the system. Also, neither the user him or herself nor any administrator in the system would have knowledge of the entirety of administrative tasks that the user is actually authorized to perform across the information system. Additionally, there may exist excessive entitlements in the system, and these may end up granting entitlements that may be in violation of security policy. Finally, a simple evaluation of ACLs on objects will neither reveal the cumulative set of operations that are authorized by the presence of the ACEs in that ACL, nor will they reveal information about the cumulative set of users who may entitled to performing the various administrative tasks that corresponds to the presence of the permissions specified in these ACEs.
Thus at any given point in time, an ordinary user or a delegated administrator of the system may very well be entitled to creating new user accounts or groups, resetting the passwords of or disabling a large number of user accounts, modifying potentially sensitive and confidential information on user accounts, modifying the group membership of a large number of security groups each of which in turn may have been used at thousands of places in the system to specify access on thousands of resources, etc.
This problem is not limited to the existence of large numbers of user entitlements, each of which may span various administrative categories and in a direct or indirect manner be related to some permission granted on one of thousands of objects that exist in the Active Directory. It in fact extends to include access that may be provisioned for thousands of users to access thousands of hosts that are a part of the IT infrastructure and to further include access that may be provisioned to thousands of information assets that reside on these hosts—examples of such information assets include trade secrets, product blue-prints, business plans, competitive strategies, business intelligence, strategic and tactical plans, financials, customers records, employee records, operational and security blue-prints, information exchange between employees, customers, executives & other stakeholders etc., all of which may exist as individual documents or as contents of databases, access to each of which could be obtained directly or via a service. In its entirety, this is a real problem and one that poses a major challenge in the ability of organizations around the world to secure access to their information and IT assets.
In any moderate to large information system, there exist hundreds of thousands individual authorization intent specifications each of which is attached to one of hundreds of thousands of information assets, multiple copies of each of which may reside on thousands of computing devices (IT assets), each gated by one of many different kinds of resource managers that exist across the information system and each one authorizing an operation or a task, the inference of which requires contextual knowledge which is usually an inferred function of the type of asset being protected and the specific nature of access specified in the authorization entitlement.
Even at best, any such measures would fall far short in their attempts to arrive at a meaningful (complete and accurate) list of a user's cumulative entitlements across the information system, primarily because the vast amounts of information that would have to be assessed, sifted and subsequently processed (to account for context), to arrive at a meaningful list, and the extraordinarily inordinate amount of time that a manual assessment of the same would require, would in itself make any manual attempts virtually useless, especially considering that it in order for such information to be at all useful, it would have to be of arrived at very quickly, given its time sensitive nature.
Benefits of Cumulative Assess Entitlements
There are numerous benefits in being successfully able to assess the cumulative assessments of an entity in an information system. Such an assessment could be used to determine the set of all administrative tasks or business functions that a user is entitled to performing across the information system. It could also be used to discover the presence of insecure or weak or unauthorized permissions that allow a user to perform some task that he or she should not be allowed to perform. It may further be used to determine the set of all users who may be able to perform a given task in an information system. It may also be used to identify the presence of privilege escalation paths in the system. Additional benefits of this ability will be apparent to those of ordinary skill in the art.
One's ability to successfully and accurately assess the entitlements of an entity in a system is dependent on numerous factors including the nature of authorization intent specifications that exist in the system, the use of security affiliations, the presence of different types of resource managers that collectively gate access to the various information and IT assets across an information system, the vast expanse of the information system and the inclusion of numerous other dynamics that may be specific to the implementation of the authorization model underlying the various parts of an information system.